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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards" , which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://www.etsi.org/ipr) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ECMA on behalf of its members and those of the European 
Telecommunications Standards Institute (ETSI). 



Brief History 



The present document is one of a series of ECMA Standards defining the interworking of services and signalling 
protocols deployed in Corporate telecommunication Networks (CN). The series uses telecommunication concepts as 
developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as 
defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00194. 

The present document defines the signalling protocol interworking for call diversion supplementary services between a 
Private Integrated Services Network (PISN) and a packet-based private telecommunications network based on the 
Internet Protocol (IP). It is further assumed that the protocol for the PISN part is that defined for the Q reference point 
(QSIG) and that the protocols for the IP-based network are based on ITU-T Recommendation H.323. 

The present document is based upon the practical experience of ECMA member companies and the results of their 
active and continuous participation in the work of ISO/IEC JTCl, ITU-T, ETSI and other international and national 
standardization bodies. It represents a pragmatic and widely based consensus. 

The present document has been adopted by the ECMA General Assembly of June 2000. 
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Scope 



The present document specifies signalling interworking between "QSIG" and "H.323" in support of call diversion 
supplementary services within a Corporate telecommunication Network (CN). 

"QSIG" is a signalling protocol that operates at the Q reference point between Private Integrated Services eXchanges 
(PINX) within a Private Integrated Services Network (PISN). The Q reference point is defined in ECMA-133 [1]. A 
PISN provides circuit-switched basic services and supplementary services to its users. QSIG is specified in other 
ECMA Standards, in particular ECMA-143 [2] (call control in support of basic services), ECMA-165 [3] (generic 
functional protocol for the support of supplementary services) and a number of standards specifying individual 
supplementary services. ECMA-174 [4] specifies the QSIG protocol in support of call diversion services. 

"H.323" is a set of signalling protocols for the support of voice or multimedia communication within a packet network, 
in particular a packet network that uses the Internet Protocol (IP) as its network layer protocol (IP network). H.323 
signalling protocols operate between endpoints in an IP network, either indirectly via one or more gatekeepers, or 
directly. An endpoint can be a terminal or a gateway to another network. H.323 is an "umbrella" recommendation 
referring to various ITU-T recommendations, in particular H. 225.0 [6] and H.245 [7] (basic communication 
capabilities) and Recommendation H.450.1 [9] (generic functional protocol for the support of supplementary services). 
ITU-T Recommendation H.450.3 [10] specifies the H.323 protocol in support of call diversion services. 

NOTE: H.450.3 applies only to the 1998 version of ITU-T Recommendation H.323 [8] (also known as H.323 
version 2) and to later versions. 

In both ECMA-174 [4] (QSIG) and ITU-Recommendation H.450.3 [10] (H.323), the call diversion supplementary 
services are Call Forwarding Unconditional (SS-CFU), Call Forwarding Busy (SS-CFB), Call Forwarding No Reply 
(SS-CFNR) and Call Deflection (SS-CD). These supplementary services apply during call establishment and provide 
diversion of an incoming call to another destination. 

Interworking between QSIG and H.323 permits a call originating at a user of a PISN to terminate at a user of an IP 
network, or a call originating at a user of an IP network to terminate at a user of a PISN. The present document provides 
the following additional capabilities: 

a call originating from a PISN and destined for a user of an H.323 network to be diverted by the H.323 network 
to an alternative destination; 

a call originating from an H.323 network and destined for a user of a PISN to be diverted by the PISN to an 
alternative destination; 

a call destined for a user of a PISN to be diverted to an alternative destination where that alternative destination 
is in an H.323 network; 

a call destined for a user of an H.323 network to be diverted to an alternative destination where that alternative 
destination is in a PISN. 

The present document is applicable to any interworking unit that can act as a gateway between a PISN employing QSIG 
and an IP network employing H.323. 



2 Conformance 

In order to conform to the present document, a gateway shall satisfy the requirements identified in the Implementation 
Conformance Statement (ICS) proforma in annex A. 
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4 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

4.1 External definitions 

The present document uses the following terms defined in other documents: 

Call: (ECMA-307) 

Corporate telecommunication Network (CN): (ECMA-307) 

Endpoint: (ITU-T Recommendation H.323) 

Gatekeeper: (ITU-T Recommendation H.323) 

IP network: (ECMA-307) 

Private Integrated Services Network (PISN): (ECMA-307) 
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Private Integrated services Network eXchange (PINX): (ECMA-133) 

Additionally the definitions in ECMA-174 and ITU-T Recommendation H.450.3 apply as appropriate. 

4.2 Other definitions 

4.2.1 Association D 

Signalling association between entity D and entity G. 

4.2.2 Association E 

Signalling association between entity E and entity G. 

4.2.3 Association F 

Signalling association between entity F and entity G. 

4.2.4 Association G 

Signalling association between entity G and entity H. 

4.2.5 Entity A 

Signalling entity at the PINX or H.323 endpoint serving the calling user (user A). 

4.2.6 Entity B 

Signalling entity at the PINX serving the diverting user (user B) or H.323 entity that invokes diversion on behalf of 
user B. 

4.2.7 Entity B' 

Signalling entity at the H.323 endpoint serving user B. 

4.2.8 Entity C 

Signalling entity at the PINX or H.323 endpoint serving the diverted-to-user (user C). 

4.2.9 Entity D 

Signalling entity at the PINX or H.323 endpoint serving an activating user. 

4.2.10 Entity E 

Signalling entity at the PINX or H.323 endpoint serving a deactivating user. 

4.2.11 Entity F 

Signalling entity at the PINX or H.323 endpoint serving an interrogating user. 

4.2.12 Entity G 

Signalling entity for activation / deactivation / interrogation at a PINX or H.323 endpoint serving a diverting endpoint. 



ETSI 



9 ETSI TS 101 906 VI. 1.1 (2001-04) 

4.2.13 Entity H 

Signalling entity for restriction checking at a PINX or H.323 endpoint serving a diverted-to endpoint. 

4.2.14 Gateway 

A gateway as defined in H.323 specifically for the purpose of interworking with a network employing QSIG. 

4.2.15 Leg A 

Call segment that lies between entity A and the rerouting entity. 

4.2.16 LegB 

Call segment that lies between the rerouting entity and entity B. 

4.2.17 LegB' 

Call segment that lies between entity B and entity B'. 

4.2.18 Lege 

Call segment that lies between the rerouting entity and entity C. 

4.2.19 Rerouting entity 

Signalling entity that initiates the rerouting of a call towards user C and clears the call towards user B. 

4.2.20 Scenario A1 

Interworking arrangement in which entity A (PINX A) is in the PISN and the rerouting entity is in the IP network. 

4.2.21 Scenario A2 

Interworking arrangement in which entity A (endpoint A) is in the IP network and the rerouting entity is in the PISN. 

4.2.22 Scenario B1 

Interworking arrangement in which entity B (PINX B) is in the PISN and the rerouting entity is in the IP network. 

4.2.23 Scenario B2 

Interworking arrangement in which entity B (diverting endpoint or its gatekeeper) is in the IP network and the rerouting 
entity is in the PISN. 

4.2.24 Scenario CI 

Interworking arrangement in which entity C (PINX C) is in the PISN and the rerouting entity is in the IP network. 

4.2.25 Scenario C2 

Interworking arrangement in which entity C (endpoint C) is in the IP network and the rerouting entity is in the PISN. 
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4.2.26 Scenario D1 

Interworking arrangement in which entity D (PINX D) is in the PISN and entity G (endpoint G) is in the IP network. 

4.2.27 Scenario D2 

Interworking arrangement in which entity D (endpoint D) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.28 Scenario E1 

Interworking arrangement in which entity E (PINX E) is in the PISN and entity G (endpoint G) is in the IP network. 

4.2.29 Scenario E2 

Interworking arrangement in which entity E (endpoint E) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.30 Scenario F1 

Interworking arrangement in which entity F (PINX F) is in the PISN and entity G (endpoint G) is in the IP network. 

4.2.31 Scenario F2 

Interworking arrangement in which entity F (endpoint F) is in the IP network and entity G (PINX G) is in the PISN. 

4.2.32 Scenario G1 

Interworking arrangement in which entity G (PINX G) is in the PISN and entity H (endpoint H) is in the IP network. 

4.2.33 Scenario G2 

Interworking arrangement in which entity G (endpoint G) is in the IP network and entity H (PINX H) is in the PISN. 



5 Acronyms 



APDU Application Protocol Data Unit 

CN Corporate telecommunication Network 

ICS Implementation Conformance Statement 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 

PISN Private Integrated Services Network 

SS-CD Supplementary Service Call Deflection 

SS-CFB Supplementary Service Call Forwarding Busy 

SS-CFNR Supplementary Service Call Forwarding No Reply 

SS-CFU Supplementary Service Call Forwarding Unconditional 
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6 Service architecture 

6.1 Service architecture for invocation and operation 
6.1 .1 ECMA-1 74 service architecture 

The QSIG protocol for call diversion invocation and operation is based around four signalling entities or PINX types: 

entity A - the PINX serving the calling user (user A); 

entity B - the PINX serving the diverting user (user B); 

entity C - the PINX serving the diverted-to user (user C); 

rerouting entity - the PINX that initiates the rerouting of the call towards user C and clears the call towards 
user B. 

Where a user is in another network, the role of entity A, entity B or entity C is performed by the other network, the 
gateway PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway 
PINX. 

This can be represented diagrammatically as shown in figure 1 . 





Leg A 




LegB^^ 
Lege \^ 


Entity B 


Entity A 


Rerouting 
entity 












Entity 



Figure 1 : Call diversion architecture for QSIG 

From this it can be seen that there are three segments or "legs" to the call: 

leg A from entity A to the rerouting entity; 

leg B from the rerouting entity to entity B; 

leg C from the rerouting entity to entity C. 

The QSIG protocol supports each of these three legs. 

The rerouting entity is constrained to be collocated with (in the same PINX as) entity A or entity B (or both if entity A 
and entity B are collocated). In addition, entity C can be collocated with the rerouting entity (and therefore with entity A 
and/or entity B). When an entity is collocated with the rerouting entity, the leg of the call concerned is internal to the 
physical PINX and therefore the QSIG protocol for that leg does not apply. 
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6.1 .2 H.450.3 service architecture 

The architecture shown above for QSIG apphes also to H.450.3, except that PINXs are replaced by H.323 entities as 
follows: 

entity A - the calling endpoint; 

entity B - the entity that invokes diversion on behalf of the diverting user; 

entity B' - the diverting endpoint; 

entity C - the diverted-to endpoint; 

rerouting entity - the entity that initiates the rerouting of the call towards user C and clears the call towards 
user B. 

Where a user is in another network, the role of entity A, entities B and B' or entity C is performed by the other network, 
the gateway, or the two in combination. However, from the H.450.3 point of view the role is performed by the gateway. 

This can be represented diagrammatically as shown in figure 2: 





Leg A 
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Entity 





Figure 2: Call diversion architecture for H.323 

From this it can be seen that there are four segments or "legs" to the call: 

leg A from entity A to the rerouting entity; 

leg B from the rerouting entity to entity B; 

leg B' from entity B to entity B'; 

leg C from the rerouting entity to entity C. 

The H.450.3 protocol supports each of these four legs. 

Entity B is either collocated with entity B' at the diverting endpoint or is located separately in a gatekeeper acting on 
behalf of the diverting endpoint, e.g. for situations where B' is switched off since B' can be a PC. 

The rerouting entity can be collocated with entity A or entity B. Alternatively it can be at a separate device such as a 
gatekeeper or proxy. 
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6.1 .3 Scenarios for interworking 



The architectures for QSIG and H. 450.3 are very similar. The only difference is the absence of entity B' and leg B' from 
the QSIG architecture. This is not a fundamental difference, but merely reflects the fact that entity B' and leg B' are 
outside the scope of QSIG and therefore no QSIG protocol is required for leg B'. Normally leg B' would correspond to 
the PISN access. 

This means that the H.450.3 architecture is applicable to the inter-networking situation between an IP network and a 
PISN, where one or more of the users involved are served by the IP network and the others are served by the PISN. 

In figure 2 interworking between H.450.3 and QSIG could theoretically occur on any of the four legs. However, 
interworking on leg B' is of less practical use (a network is unlikely to invoke diversion on behalf of a diverting user in 
another network), and also is not possible because there is no support for leg B' in QSIG. Therefore in practice the 
possible points of interworking occur on legs A, B and C. 

For each of the three possible points of interworking, two scenarios arise, depending on which side of the interworking 
point the PISN lies. This gives 6 scenarios in total that need to be considered: 

- Scenario Al: Entity A (PINX A) in PISN, rerouting entity in IP network; 
Scenario A2: Entity A (endpoint A) in IP network, rerouting entity in PISN; 

- Scenario B 1 : Entity B (PINX B) in PISN, rerouting entity in IP network; 

Scenario B2: Entity B (diverting endpoint or its gatekeeper) in IP network, rerouting entity in PISN; 

- Scenario CI: Entity C (PINX C) in PISN, rerouting entity in IP network; 

Scenario C2: Entity C (endpoint C) in IP network, rerouting entity in PISN. 

It is possible for more than one scenario to apply to the same call. For example, if entity A and the rerouting entity are 
in a PISN and entities B and C are in the same IP network or different IP networks, interworking according to 
scenario B2 will apply on leg B and interworking according to scenario C2 will apply on leg C. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. 

Multiple scenarios can also occur because of multiple (chained) diversions. 

6.1 .4 Determination of tine location of tine rerouting entity winen 
interworking 

The particular scenario (or scenarios) that applies depends not only on the location of the users concerned but also on 
the location of the rerouting entity. In each of the scenarios it is possible to locate the rerouting entity within the 
gateway. However, functionally the rerouting entity is separate from the point of interworking and belongs to user B's 
network. When this occurs, interworking occurs on leg A (scenario Al or A2). 

The possibility of sitting the rerouting entity at the gateway arises when the gateway receives a rerouting request (QSIG 
or H.450.3 callRerouting invoke APDU) from entity B. Instead of creating a rerouting entity at the gateway, the 
gateway can choose to pass the rerouting request on into the other network towards entity A. In this case interworking 
occurs on leg B (scenario Bl or B2). 

In either case, interworking can also occur on leg C (scenario CI or C2) if entity C is not in the same type of network as 
the rerouting entity. 

The gateway's decision whether to provide the rerouting entity is an implementation matter. This can, but need not, take 
account of the address of user C. The behaviour of the rerouting entity, if provided at the gateway, is outside the scope 
of the present document and is assumed to be in accordance with the requirements of ECMA-174 [4] (for rerouting 
requests received from the PISN) or in accordance with the requirements of H.450.3 [10] (for rerouting requests 
received from the IP network). 



£75/ 



14 



ETSI TS 101 906 VI. 1.1 (2001-04) 



6.2 Service architecture for activation, deactivation and 
interrogation 

6.2.1 ECIVIA-1 74 service architecture 

The QSIG protocol for call diversion activation, deactivation and interrogation is based around three signalling entities 
or PINX types: 

entity D - a PINX serving an activating user; 

entity E - a PINX serving a deactivating user; 

entity F - a PINX serving an interrogating user; 

entity G - a PINX serving a diverting user; 

entity H - a PINX serving a diverted-to user. 

Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway 
PINX or the two in combination. However, from the QSIG point of view the role is performed by the gateway PINX. 

This can be represented diagrammatically as shown in figure 3. 




Association G 



Entity H 



Figure 3: Call diversion activation / deactivation / interrogation architecture for QSIG 

From this it can be seen that there are four associations between entities: 

association D between entity D and entity G; 

association E between entity E and entity G; 

association F between entity F and entity G; 

association G between entity G and entity H. 

Associations D, E and F apply to activation, deactivation and interrogation respectively. Association G applies to 
activation and allows entity G to check with entity H whether there are any restrictions that prevent activation of 
diversion. 

The QSIG protocol supports each of these four associations. 
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6.2.2 H.450.3 service architecture 

The architecture shown above for QSIG apphes also to H.450.3, except that PINXs are replaced by H.323 entities as 
follows: 

entity D - an activating endpoint; 

- entity E - a deactivating endpoint; 

entity F - an interrogating endpoint; 

entity G - a diverting endpoint or gatekeeper; 

entity H - a diverted-to endpoint. 

Where a user is in another network, the role of the entity concerned is performed by the other network, the gateway, or 
the two in combination. However, from the H.450.3 point of view the role is performed by the gateway. 

As for QSIG, there are four associations: D, E, F and G. 

The H.450.3 protocol supports each of these four associations. 



6.2.3 Scenarios for interworl^ing 



Because the architectures for QSIG and H.450.3 are the same, this architecture is applicable to the inter-networking 
situation between an IP network and a PISN, where one or more of the users involved are served by the IP network and 
the others are served by the PISN. 

In figure 3, interworking between H.450.3 and QSIG can occur on any of the four associations. 

For each of the four possible points of interworking, two scenarios arise, depending on which side of the interworking 
point the PISN lies. This gives 8 scenarios in total that need to be considered: 

- Scenario Dl: Entity D (PINX D) in PISN, entity G (endpoint G) in IP network; 

- Scenario D2: Entity D (endpoint D) in IP network, entity G (PINX G) in PISN; 

- Scenario El : Entity E (PINX E) in PISN, entity G (endpoint G) in IP network; 

- Scenario E2: Entity E (endpoint E) in IP network, entity G (PINX G) in PISN; 

- Scenario Fl : Entity F (PINX F) in PISN, entity G (endpoint G) in IP network; 

- Scenario F2: Entity F (endpoint F) in IP network, entity G (PINX G) in PISN; 

- Scenario Gl : Entity G (PINX G) in PISN, entity H (endpoint H) in IP network; 

- Scenario G2: Entity G (endpoint G) in IP network, entity H (PINX H) in PISN. 

A point of interworking will be implemented in a gateway, which acts as both an H.323 endpoint from the point of view 
of the IP network and an end PINX from the point of view of the PISN. 

7 Protocol interworking - General requirements 

Protocol interworking between H.323 and QSIG for call diversion supplementary services shall be in accordance with 
ECMA-307 [5], as modified by the requirements of clause 8. 

When transmitting an APDU in one protocol as a result of receiving the corresponding APDU in the other protocol, the 
mapping of elements in the received APDU to corresponding elements in the transmitted APDU shall be in accordance 
with ECMA-307 [5], where applicable. Optional elements of one protocol that have no corresponding element in the 
other protocol shall be discarded if received. 
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8 



Protocol interworking - Messages and APDUs 



In the rules specified below for the different scenarios, the following shall apply: 

1) If the required action is to transmit a QSIG or H.323 FACILITY message but the call state does not permit a 
FACILITY message to be sent at that time, the action to be taken is an implementation matter. 

2) If the required action is to include an APDU in a transmitted QSIG or H.323 message conditional upon that 
message being transmitted and that message is not to be transmitted (owing to basic call interworking 
considerations), the action to be taken is an implementation matter. 

3) If the required action is dependent on the call independent signalling connection extending or being able to be 
extended into the other network and this cannot be achieved, the action to be taken is an implementation matter. 



8.1 



Scenario A1 



A gateway that supports scenario Al shall behave in accordance with the rules of table 1, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network. 

Table 1 : Message and APDU handling requirements for scenario Al 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 divertingLeglnformationI involve APDU in the 
bacl<ward direction, no H.323 CONNECT message 
having been received. 


Transmit a OSIG FACILITY message containing a 
OSIG divertingLeglnformationI involve APDU if the 
OSIG call state permits. 


2 


Receipt of an H.323 CONNECT message containing an 
H.323 divertingLeglnformationI involve APDU. 


If a OSIG CONNECT message is to be transmitted, 
include in the OSIG CONNECT message a OSIG 
divertingLeglnformationI involve APDU. 


3 


Receipt of an H.323 ALERTING message containing an 
H.323 divertingLeglnformation3 invol<e APDU. 


If a OSIG ALERTING message is to be transmitted, 
include in the OSIG ALERTING message a OSIG 
divertingLeglnformation3 invol<e APDU. 


4 


Receipt of an H.323 FACILITY message containing an 
H.323 divertingLeglnformation3 involve APDU in the 
bacl<ward direction, no H.323 CONNECT message 
having been received. 


Transmit a OSIG FACILITY message containing a 
OSIG divertingLeglnformation3 invol<e APDU if the 
OSIG call state permits. 


5 


Receipt of an H.323 CONNECT message containing an 
H.323 divertingLeglnformation3 invol<e APDU. 


If a OSIG CONNECT message is to be transmitted, 
include in the OSIG CONNECT message a OSIG 
divertingLeglnformation3 invol<e APDU. 
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8.2 



Scenario A2 



A gateway that supports scenario A2 shall behave in accordance with the rules of table 2, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN. 

Table 2: Message and APDU handling requirements for scenario A2 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
OSIG divertingLeglnformationI invoke APDU in the 
backward direction, no QSIG CONNECT message 
having been received. 


Transmit an H.323 FACILITY message containing 
an H.32S divertingLeglnformationI invoke APDU if 
the H.323 call state permits. 


2 


Receipt of a QSIG CONNECT message containing a 
OSIG divertingLeglnformationI invoke APDU. 


If an H.323 CONNECT message is to be 
transmitted, include in the H.323 CONNECT 
message an H.323 divertingLeglnformationI invoke 
APDU. 


3 


Receipt of a QSIG ALERTING message containing a 
OSIG divertingLeglnformationS invoke APDU. 


If an H.323 ALERTING message is to be 
transmitted, include in the H.323 ALERTING 
message an H.323 divertingLeglnformationS invoke 
APDU. 


4 


Receipt of a QSIG FACILITY message containing a 
OSIG divertingLeglnformationS invoke APDU in the 
backward direction, no OSIG CONNECT message 
having been received. 


Transmit an H.323 FACILITY message containing 
an H.323 divertingLeglnformationS invoke APDU if 
the H.323 call state permits. 


5 


Receipt of a QSIG CONNECT message containing a 
OSIG divertingLeglnformationS invoke APDU. 


If an H.S23 CONNECT message is to be 
transmitted, include in the H.S23 CONNECT 
message an H.S2S divertingLeglnformationS invoke 
APDU. 


6 


Receipt of a QSIG NOTIFY message containing 
notification "call is diverting" (see note 1). This can be 
accompanied by notification "psslleNotification" with 
embedded public ISDN Redirection number 
information element. 


Transmit an H.323 FACILITY message containing 
an H.32S divertingLeglnformationI invoke APDU if 
the H.323 call state permits (see note 2). 


7 


Receipt of a QSIG CONNECT message containing no 
OSIG divertingLeglnformationS invoke APDU, 
subsequent to transmitting an H.S2S FACILITY 
message containing an H.323 
divertingLeglnformationI invoke APDU in accordance 
with rule 6. 


If an H.S23 CONNECT message is to be 
transmitted, include in the H.S23 CONNECT 
message an H.S2S divertingLeglnformationS invoke 
APDU. 


NOTE 1 : This can arise as a result of the PISN routing the call on into a public ISDN, where diversion occurs. 
NOTE 2: If no embedded public ISDN Redirection number information element is received, mandatory element 

nominatedNr in the H.323 divertingLeglnformationI invoke APDU shall be coded to indicate that no address 

is available. 
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8.3 



Scenario B1 



A gateway that supports scenario Bl shall behave in accordance with the rules of table 3, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network, or the receipt of a QSIG 
message from entity B. 

Table 3: Message and APDU handling requirements for scenario Bl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG FACILITY message containing a 
QSIG call Rerouting invoke APDU in the backward 
direction, no QSIG CQNNECT message having been 
received. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting invoke APDU if the H.323 call 
state permits. 


2 


Receipt of an H.323 FACILITY message containing an 
H.323 callRerouting return result APDU in response to 
an H.323 callRerouting invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callRerouting return result APDU if the QSIG 
call state permits. 


3 


Receipt of an H.323 RELEASE COIVIPLETE message 
containing an H.323 callRerouting return result APDU in 
response to an H.323 callRerouting invoke APDU. 


Transmit a QSIG DISCONNECT message containing 
a QSIG callRerouting return result APDU if the QSIG 
call state permits. 


4 


Receipt of an H.323 FACILITY message containing an 
H.323 callRerouting return error APDU in response to 
an H.323 callRerouting invoke APDU. 


Transmit a QSIG FACILITY message containing a 
QSIG callRerouting return error APDU if the QSIG call 
state permits. 


5 


Receipt of an H.323 RELEASE COIVIPLETE message 
containing an H.323 callRerouting return error APDU in 
response to an H.323 callRerouting invoke APDU. 


Transmit a QSIG DISCONNECT message containing 
a QSIG callRerouting return error APDU if the QSIG 
call state permits. 


6 


Receipt of an H.323 FACILITY message containing an 
H.323 cfnrDivertedLegFailed invoke APDU in the 
forward direction. 


Transmit a QSIG FACILITY message containing a 
QSIG CfnrDivertedLegFailed invoke APDU if the QSIG 
call state permits. 



8.4 



Scenario B2 



A gateway that supports scenario B2 shall behave in accordance with the rules of table 4, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN, or receipt of an H.323 message from 
entity B. 

Table 4: Message and APDU handling requirements for scenario B2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 FACILITY message containing an 
H.323 callRerouting invoke APDU in the backward 
direction, no H.323 CONNECT message having been 
received. 


Transmit a QSIG FACILITY message containing a 
QSIG callRerouting invoke APDU if the QSIG call 
state permits. 


2 


Receipt of a QSIG FACILITY message containing a 
QSIG callRerouting return result APDU in response to a 
QSIG callRerouting invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting return result APDU if the H.323 
call state permits. 


3 


Receipt of a QSIG DISCONNECT message containing 
a QSIG callRerouting return result APDU in response to 
a QSIG callRerouting invoke APDU. 


Transmit an H.323 RELEASE COIVIPLETE message 
containing an H.323 callRerouting return result APDU 
if the H.323 call state permits. 


4 


Receipt of a QSIG FACILITY message containing a 
QSIG callRerouting return error APDU in response to a 
QSIG callRerouting invoke APDU. 


Transmit an H.323 FACILITY message containing an 
H.323 callRerouting return error APDU if the H.323 
call state permits. 


4 


Receipt of a QSIG DISCONNECT message containing 
a QSIG callRerouting return error APDU in response to 
a QSIG callRerouting invoke APDU. 


Transmit an H.323 RELEASE COIVIPLETE message 
containing an H.323 callRerouting return error APDU 
if the H.323 call state permits. 


6 


Receipt of a QSIG FACILITY message containing a 
QSIG CfnrDivertedLegFailed invoke APDU in the 
forward direction. 


Transmit an H.323 FACILITY message containing an 
H.323 CfnrDivertedLegFailed invoke APDU if the 
H.323 call state permits. 
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8.5 



Scenario C1 



A gateway that supports scenario CI shall behave in accordance with the rules of table 5, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from a rerouting 
entity, whether this be located in the gateway or in a separate physical entity in the IP network, or receipt of a QSIG 
message from entity C. 

Table 5: Message and APDU handling requirements for scenario CI 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 SETUP message containing an 
H.323 divertingLeglnformation2 invol<e APDU. 


If a QSIG SETUP message is to be transmitted, include 
in the QSIG SETUP message a QSIG 
divertingLeglnformation2 invol<e APDU. 


2 


Receipt of a QSIG ALERTING message containing a 
QSIG divertingLeglnformation3 involve APDU. 


If an H.323 ALERTING message is to be transmitted, 
include in the H.323 ALERTING message an H.323 
divertingLeglnformation3 invoke APDU. 


3 


Receipt of a QSIG FACILITY message containing a 
QSIG divertingLeglnformation3 involve APDU in the 
backward direction, no QSIG CONNECT message 
having been received. 


Transmit an H.323 FACILITY message containing an 
H.323 divertingLeglnformation3 invoke APDU if the 
H.323 call state permits. 


4 


Receipt of a QSIG CQNNECT message containing a 
QSIG divertingLeglnformation3 involve APDU. 


If an H.323 CONNECT message is to be transmitted, 
include in the H.323 CONNECT message an H.323 
divertingLeglnformation3 invoke APDU. 



8.6 



Scenario C2 



A gateway that supports scenario C2 shall behave in accordance with the rules of table 6, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from a rerouting entity, 
whether this be located in the gateway or in a separate physical entity in the PISN, or the receipt of an H.323 message 
from entity C. 

Table 6: Message and APDU handling requirements for scenario C2 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG SETUP message containing a QSIG 
divertingLeglnformation2 invoke APDU. 


If an H.323 SETUP message is to be transmitted, 
include in the H.323 SETUP message an H.323 
divertingLeglnformation2 invoke APDU. 


2 


Receipt of an H.323 ALERTING message containing an 
H.323 divertingLeglnformationS invoke APDU. 


If a QSIG ALERTING message is to be transmitted, 
include in the QSIG ALERTING message a QSIG 
divertingLeglnformationS invoke APDU. 


3 


Receipt of an H.323 FACILITY message containing an 
H.323 divertingLeglnformationS invoke APDU in the 
backward direction, no QSIG CQNNECT message 
having been received. 


Transmit a QSIG FACILITY message containing a 
QSIG divertingLeglnformationS invoke APDU if the 
QSIG call state permits. 


4 


Receipt of an H.323 CQNNECT message containing an 
H.323 divertingLeglnformationS invoke APDU. 


If a QSIG CQNNECT message is to be transmitted, 
include in the QSIG CQNNECT message a QSIG 
divertingLeglnformationS invoke APDU. 
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8.7 Scenario D1 

A gateway that supports scenario Dl shall behave in accordance with the rules of table 7, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity D or an 
H.323 message from entity G. 

Table 7: Message and APDU handling requirements for scenario Dl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG activateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends or 
is able to be extended into the IP network, transmit an 
H.323 activateDiversionQ invoke APDU. 


2 


Receipt of an H.323 activateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to an H.323 activateDiversionQ 
invoke APDU. 


Transmit a QSIG activateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 activateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to an H.323 activateDiversionQ 
invoke APDU. 


Transmit a QSIG activateDiversionQ return error APDU. 



8.8 



Scenario D2 



A gateway that supports scenario D2 shall behave in accordance with the rules of table 8, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity D or a 
QSIG message from entity G. 

Table 8: Message and APDU handling requirements for scenario D2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 activateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends or 
is able to be extended Into the PISN, transmit a QSIG 
activateDiversionQ invoke APDU. 


2 


Receipt of a QSIG activateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to a QSIG activateDiversionQ 
invoke APDU. 


Transmit an H.323 activateDiversionQ return result 
APDU. 


3 


Receipt of a QSIG activateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to a QSIG activateDiversionQ 
invoke APDU. 


Transmit an H.323 activateDiversionQ return error 
APDU. 
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8.9 



Scenario E1 



A gateway that supports scenario El shall behave in accordance with the rules of table 9, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity E or an 
H.323 message from entity G. 

Table 9: Message and APDU handling requirements for scenario El 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG deactivateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends or 
is able to be extended into the IP network, transmit an 
H.323 deactivateDiversionQ invoke APDU. 


2 


Receipt of an H.323 deactivateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to an H.323 
deactivateDiversionQ invoke APDU. 


Transmit a QSIG deactivateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 deactivateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to an H.323 
deactivateDiversionQ invoke APDU. 


Transmit a QSIG deactivateDiversionQ return error 
APDU. 



8.10 Scenario E2 

A gateway that supports scenario E2 shall behave in accordance with the rules of table 10, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity E or a 
QSIG message from entity G. 

Table 10: Message and APDU handling requirements for scenario E2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 deactivateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the PISN, transmit a 
QSIG deactivateDiversionQ invoke APDU. 


2 


Receipt of a QSIG deactivateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to a QSIG deactivateDiversionQ 
invoke APDU. 


Transmit an H.323 deactivateDiversionQ return result 
APDU. 


3 


Receipt of a QSIG deactivateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to a QSIG deactivateDiversionQ 
invoke APDU. 


Transmit an H.323 deactivateDiversionQ return error 
APDU. 



£75/ 



22 



ETSI TS 101 906 VI. 1.1 (2001-04) 



8.11 Scenario F1 

A gateway that supports scenario Fl shall behave in accordance with the rules of table 11, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity F or an 
H.323 message from entity G. 

Table 11 : Message and APDU handling requirements for scenario F1 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG interrogateDiversionQ invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the IP network, transmit 
an H.323 InterrogateDiversionQ invoke APDU. 


2 


Receipt of an H.323 interrogateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to an H.323 
interrogateDiversionQ invoke APDU. 


Transmit a QSIG InterrogateDiversionQ return result 
APDU. 


3 


Receipt of an H.323 interrogateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to an H.323 
InterrogateDiversionQ invoke APDU. 


Transmit a QSIG InterrogateDiversionQ return error 
APDU. 



8.12 Scenario F2 

A gateway that supports scenario F2 shall behave in accordance with the rules of table 12, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity F or a 
QSIG message from entity G. 

Table 12: Message and APDU handling requirements for scenario F2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 interrogateDiversionQ invoke 
APDU carried on a call independent signalling 
connection. 


If the call independent signalling connection extends 
or is able to be extended into the PISN, transmit a 
QSIG interrogateDiversionQ invoke APDU. 


2 


Receipt of a QSIG interrogateDiversionQ return result 
APDU carried on a call independent signalling 
connection in response to a QSIG 
InterrogateDiversionQ invoke APDU. 


Transmit an H.323 interrogateDiversionQ return result 
APDU. 


3 


Receipt of a QSIG interrogateDiversionQ return error 
APDU carried on a call independent signalling 
connection in response to a QSIG 
InterrogateDiversionQ invoke APDU. 


Transmit an H.323 InterrogateDiversionQ return error 
APDU. 
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8.13 Scenario G1 

A gateway that supports scenario Gl shall behave in accordance with the rules of table 13, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of a QSIG message from entity G or an 
H.323 message from entity H. 

Table 13: Message and APDU handling requirements for scenario Gl 



Rule 


Condition 


Required action 


1 


Receipt of a QSIG checkRestriction invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the IP network, transmit 
an H.323 checkRestriction invoke APDU. 


2 


Receipt of an H.323 checkRestriction return result 
APDU carried on a call independent signalling 
connection in response to an H.323 checkRestriction 
invoke APDU. 


Transmit a QSIG checkRestriction return result APDU. 


3 


Receipt of an H.323 checkRestriction return error APDU 
carried on a call independent signalling connection in 
response to an H.323 checkRestriction invoke APDU. 


Transmit a QSIG checkRestriction return error APDU. 



8.14 Scenario G2 

A gateway that supports scenario G2 shall behave in accordance with the rules of table 14, by carrying out the required 
action when a given condition occurs. Each condition applies to the receipt of an H.323 message from entity G or a 
QSIG message from entity H. 

Table 14: Message and APDU handling requirements for scenario G2 



Rule 


Condition 


Required action 


1 


Receipt of an H.323 checkRestriction invoke APDU 
carried on a call independent signalling connection. 


If the call independent signalling connection extends 
or is able to be extended into the PISN, transmit a 
QSIG CheckRestriction invoke APDU. 


2 


Receipt of a QSIG checkRestriction return result APDU 
carried on a call independent signalling connection in 
response to a QSIG checkRestriction invoke APDU. 


Transmit an H.323 checkRestriction return result 
APDU. 


3 


Receipt of a QSIG checkRestriction return error APDU 
carried on a call independent signalling connection in 
response to a QSIG checkRestriction invoke APDU. 


Transmit an H.323 checkRestriction return error 
APDU. 
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Annex A (normative): 

Implementation Conformance Statement (ICS) proforma 



Notwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that 
users of the present document may freely reproduce the ICS proforma in this annex so that it can be used for its 
intended purposes and may further publish the completed ICS. 



A.1 Introduction 

A.1 .1 Purpose of an ICS proforma 

The supplier of an implementation which is claimed to conform to the present document shall complete the following 
Implementation Conformance Statement (ICS) proforma. 

A completed ICS proforma is the ICS for the implementation in question. The ICS is a statement of which capabilities 
and options have been implemented for a given specification. 

The ICS can have a number of uses, including use: 

by the implementor, as a check list for implementations to reduce the risk of unintended non-conformance, 
e.g. through oversight; 

by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the 
capabilities of the implementation, stated relative to the common basis for understanding provided by the 
Standard's ICS proforma; 

by the user or potential user of the implementation, as a basis for initially checking the possibility of 
interworking with another implementation - while interworking can never be guaranteed, failure to interwork can 
often be predicted from incompatible ICS; 

by a tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the 
implementation. 
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A.2 Instructions for completing the ICS proforma 
A.2.1 General structure of the ICS proforma 

The ICS proforma is a fixed format questionnaire divided into clauses each containing a group of individual items. Each 
item is identified by an item reference, the description of the item (question to be answered), and the reference(s) to the 
clause(s) that specifies (specify) the item in the main body of the present document. 

The "Conditions for Status" column contains a specification, if appropriate, of the predicate upon which a conditional 
status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this 
item is dependent on the support marked for the referenced item). 

The "Status" column indicates whether an item is applicable and if so whether support is mandatory or optional. The 
following terms are used: 

I irrelevant or out-of-scope - this capability is outside the scope of the standard to which this ICS 

proforma applies and is not subject to conformance testing in this context; 

M mandatory (the capability is required for conformance to the standard); 

N/A not applicable - in the given context, it is impossible to use the capability; no answer in the 
support column is required; 

O optional (the capability is not required for conformance to the standard, but if the capability is 

implemented it is required to conform to the specification in the present document); 

0.<n qualified optional - in this case, <n> is an integer that identifies a unique group of related optional 
items; if no additional qualification is indicated, the support of at least one of the optional items is 
required for conformance to the present document; otherwise, the qualification and logic of the 
selection among the optional items is defined below the table explicitly; 

X excluded or prohibited - there is a requirement not to use this capability in a given context. 



Answers to the questionnaire items are to be provided in the "Support" column, by simply marking an answer to 
indicate a restricted choice (Yes, No or N/A). In specific cases, the indication of explicit values may be requested. 
Where a support column box is left blank, no answer is required. 

If a "prerequisite line" (see A.2.4) is used after a clause heading or table title, and its predicate is false, no answer is 
required for the whole clause or table, respectively. 

A.2. 2 Additional Information 

Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of 
the ICS. It is not intended or expected that a large quantity will be supplied, and an ICS can be considered complete 
without any such information. Examples might be an outline of the ways in which a (single) implementation can be set 
up to operate in a variety of environments and configurations. 

References to items of Additional Information may be entered next to any answer in the questionnaire, and may be 
included in items of Exception Information. 
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A.2.3 Exception Information 



It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any 
conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be 
found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> 
reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. 

An implementation for which an Exception item is required in this way does not conform to the present document. A 
possible reason for the situation described above is that a defect in the standard has been reported, a correction for 
which is expected to change the requirement not met by the implementation. 

A.2.4 Further indications of the ICS proforma tables 

In addition to the columns of a table, the following information may be indicated: 

"Prerequisite line" 

A prerequisite line after a clause heading or table title indicates that the whole clause or the whole table is not required 
to be completed if the predicate is false. 

"Qualification" 

At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the 
description of the status "qualified optional" in clause A.2.1. 

"Comments" 

This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided 
separately (without using this box). 



A. 3 Identification of the Implementation 



A.3.1 Implementation Identification 



Supplier (see note 1) 




Contact point for queries about the ICS 
(see note 1 ) 




Implementation Name(s) and Version(s) 
(see notes 1 and 2) 




Other information necessary for full 
identification - e.g., name(s) and version(s) for 
machines and/or operating systems; System 
name(s) 




NOTE 1 : Only the first three items are required for all implementations; other information may be completed as 

appropriate in meeting the requirement for full identification. 
NOTE 2: The terms Name and Version should be interpreted appropriately to correspond with a suppliers 

terminology (e.g. Type, Series, IVIodel). 
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A.3.2 Specification for which this ICS applies 



Title 


Corporate telecommunication networks - Signalling 
interworking between QSIG and H.323 - Generic functional 
protocol for the support of supplementary services 


Version 


1.0 


Corrigenda Implemented (if applicable) 




Addenda Implemented (if applicable) 




Amendments Implemented (if applicable) 




Have any exception items been required ? 


No[ ] Yes[ ] 

(The answer Yes means that the implementation does not 

conform to the present document) (see note) 


Date of Statement 




NOTE: In this case, an explanation shall be given of the nature of non-conformance either below or on a 
separate sheet of paper: 
"Nature of non-conformance (if applicable):" 



A.4 IVIajor capabilities 



Table A.I : Major capabilities 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC1 


support rerouting entity functionality for 
handling rerouting requests received from the 
PISN 







6.1.4 


[ ]Yes [ ]No 


MC2 


support rerouting entity functionality for 
handling rerouting requests received from the 
IP network 







6.1.4 


[ ]Yes [ ]No 


MC3 


support scenario A1 




M 


6.1.3 


[]Yes 


MC4 


support scenario A2 




M 


6.1.3 


[]Yes 


MC5 


support scenario B1 


MC1 
NOT MC1 




M 


6.1.3 


[ ]Yes [ ]No 
[]Yes 


MC6 


support scenario B2 


MC2 
NOT MC2 




M 


6.1.3 


[ ]Yes [ ]No 
[lYes 


MC7 


support scenario C1 




M 


6.1.3 


[]Yes 


MC8 


support scenario C2 




M 


6.1.3 


[]Yes 


MC9 


support scenarios D1 and D2 (remote 
activation) 







6.2.3 


[ ]Yes [ ]No 


MC10 


support scenarios E1 and E2 (remote 
deactivation) 







6.2.3 


[ ]Yes [ ]No 


MC11 


support scenarios F1 and F2 (remote 
interrogation) 







6.2.3 


[ ]Yes [ ]No 


MC12 


support scenarios G1 and G2 (remote 
restriction checking for activation) 







6.2.3 


[ ]Yes [ ]No 


Comments: 
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A.5 General requirements 

Table A.2: General requirements for protocol interworking 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


GR1 


perform protocol interworking in accordance 
with ECMA-307 




M 


7 


[]Yes 


Comments: 





A. 6 Message and APDU handling 

A. 6.1 Message and APDU handling for scenario A1 

Table A.3: Message and APDU handling for scenario A1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MM 1 


behave in accordance with rule 1 for scenario 
M 




M 


8.1 


[]Yes 


MM 2 


behave in accordance with rule 2 for scenario 
M 




M 


8.1 


[]Yes 


MM 3 


behave in accordance with rule 3 for scenario 
M 




M 


8.1 


[]Yes 


MM 4 


behave in accordance with rule 4 for scenario 
M 




M 


8.1 


[]Yes 


MM 5 


behave in accordance with rule 5 for scenario 
M 




M 


8.1 


[]Yes 


Comments: 



A. 6. 2 Message and APDU handling for scenario A2 

Table A.4: Message and APDU handling for scenario A2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MA2 1 


behave in accordance with rule 1 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 2 


behave in accordance with rule 2 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 3 


behave in accordance with rule 3 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 4 


behave in accordance with rule 4 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 5 


behave in accordance with rule 5 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 6 


behave in accordance with rule 6 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 7 


behave in accordance with rule 7 for scenario 
A2 




M 


8.2 


[]Yes 


MA2 8 


behave in accordance with rule 8 for scenario 
A2 




M 


8.2 


[]Yes 


Comments: 
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A. 6. 3 Message and APDU handling for scenario B1 

Table A.5: Message and APDU handling for scenario B1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB1 1 


behave in accordance with rule 1 for scenario 
B1 


MC5 


M 


8.3 


[]Yes 


MB1 2 


behave in accordance with rule 2 for scenario 
B1 


MC5 


M 


8.3 


[]Yes 


MB1 3 


behave in accordance with rule 3 for scenario 
B1 


MC5 


M 


8.3 


[]Yes 


MB1 4 


behave in accordance with rule 4 for scenario 
B1 


MC5 


M 


8.3 


[]Yes 


Comments: 



A. 6. 4 IVIessage and APDU handling for scenario B2 

Table A.6: Message and APDU handling for scenario B2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MB2 1 


behave in accordance with rule 1 for scenario 
B2 


MC6 


M 


8.4 


[]Yes 


MB2 2 


behave in accordance with rule 2 for scenario 
B2 


MC6 


M 


8.4 


[]Yes 


MB2 3 


behave in accordance with rule 3 for scenario 
B2 


MC6 


M 


8.4 


[]Yes 


MB2 4 


behave in accordance with rule 4 for scenario 
B2 


MC6 


M 


8.4 


[]Yes 


Comments: 



A. 6. 5 Message and APDU handling for scenario C1 

Table A.7: Message and APDU handling for scenario CI 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC1 1 


behave in accordance with rule 1 for scenario 
C1 




M 


8.5 


[]Yes 


MC1 2 


behave in accordance with rule 2 for scenario 
C1 




M 


8.5 


[]Yes 


MC1 3 


behave in accordance with rule 3 for scenario 
C1 




M 


8.5 


[]Yes 


MC1 4 


behave in accordance with rule 4 for scenario 
C1 




M 


8.5 


[]Yes 


Comments: 
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A. 6. 6 Message and APDU handling for scenario C2 

Table A.8: Message and APDU handling for scenario C2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MC2 1 


behave in accordance with rule 1 for scenario 
C2 




M 


8.6 


[]Yes 


MC2 2 


behave in accordance with rule 2 for scenario 
C2 




M 


8.6 


[]Yes 


MC2 3 


behave in accordance with rule 3 for scenario 
C2 




M 


8.6 


[]Yes 


MC2 4 


behave in accordance with rule 4 for scenario 
C2 




M 


8.6 


[]Yes 


Comments: 



A. 6. 7 IVIessage and APDU handling for scenario D1 

Table A.9: Message and APDU handling for scenario D1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MD1 1 


behave in accordance with rule 1 for scenario 
D1 


MC9 


M 


8.7 


[]Yes 


MD1 2 


behave in accordance with rule 2 for scenario 
D1 


MC9 


M 


8.7 


[]Yes 


MD1 3 


behave in accordance with rule 3 for scenario 
D1 


MC9 


M 


8.7 


[]Yes 


Comments: 



A. 6. 8 Message and APDU handling for scenario D2 

Table A.10: Message and APDU handling for scenario D2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MD2 1 


behave in accordance with rule 1 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


MD2 2 


behave in accordance with rule 2 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


MD2 3 


behave in accordance with rule 3 for 
scenario D2 


MC9 


M 


8.8 


[]Yes 


Comments: 
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A. 6. 9 Message and APDU handling for scenario E1 

Table A.11 : Message and APDU handling for scenario El 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


ME1 1 


behave in accordance with rule 1 for scenario 
E1 


MC10 


M 


8.9 


[]Yes 


ME1 2 


behave in accordance with rule 2 for scenario 
E1 


MC10 


M 


8.9 


[]Yes 


ME1 3 


behave in accordance with rule 3 for scenario 
E1 


MC10 


M 


8.9 


[]Yes 


Comments: 



A. 6. 10 IVIessage and APDU handling for scenario E2 

Table A.12: Message and APDU handling for scenario E2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


ME2 1 


behave in accordance with rule 1 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


ME2 2 


behave in accordance with rule 2 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


ME2 3 


behave in accordance with rule 3 for 
scenario E2 


MC10 


M 


8.10 


[]Yes 


Comments: 



A. 6.1 1 IVIessage and APDU handling for scenario F1 

Table A.13: Message and APDU handling for scenario F1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MF1 1 


behave in accordance with rule 1 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


MF1 2 


behave in accordance with rule 2 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


MF1 3 


behave in accordance with rule 3 for 
scenario F1 


MC11 


M 


8.11 


[]Yes 


Comments: 
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A.6.12 Message and APDU handling for scenario F2 

Table A.I 4: Message and APDU handling for scenario F2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MF2 1 


behave in accordance with rule 1 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


MF2 2 


behave in accordance with rule 2 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


MF2 3 


behave in accordance with rule 3 for 
scenario F2 


MC11 


M 


8.12 


[]Yes 


Comments: 



A.6.13 IVIessage and APDU handling for scenario G1 

Table A.15: Message and APDU handling for scenario G1 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MG1 1 


behave in accordance with rule 1 for 
scenario G1 


MC12 


M 


8.13 


[]Yes 


MG1 2 


behave in accordance with rule 2 for 
scenario G1 


MC12 


M 


8.13 


[]Yes 


MG1 3 


behave in accordance with rule 3 for 
scenario G1 


MC12 


M 


8.13 


[]Yes 


Comments: 



A.6.14 IVIessage and APDU handling for scenario G2 

Table A.16: Message and APDU handling for scenario G2 



Item 


Question: 
Does the implementation...? 


Conditions for 
status 


Status 


Reference 


Support 


MG2 1 


behave in accordance with rule 1 for 
scenario G2 


MC12 


M 


8.14 


[]Yes 


MG2 2 


behave in accordance with rule 2 for 
scenario G2 


MC12 


M 


8.14 


[]Yes 


MG2 3 


behave in accordance with rule 3 for 
scenario G2 


MC12 


M 


8.14 


[]Yes 


Comments: 
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